This CIP synergizes well with the multi-validator trick and CIP-112. It would provide a large benefit to DApp throughput using current design patterns (withdraw-zero trick), that would transfer over directly to the equivalent pattern with observation scripts. I think this is a great idea.

Personally, I would like to see this extended to:
Spending Integer ScriptHash

Where integer is the index of the input that is being spent in the txInfoInputs list. I haven't really ever seen TxOutRef be used in a way other than to search for the input being unlocked.

Personally, I would like to see this extended to: Spending Integer ScriptHash

I'm very happy with any use case which supersets the functionality I propose superseding this CIP! If we get the full input (as @MicroProofs wants), or we have minor adjustments on the first argument as you say, I'm happy.

Frankly I'm moving away from any pattern which uses the spend validation directly in all my code so anything goes as long as the ScriptHash is somewhere in the constructor.

+1
It's very useful for a validator to know its own scriptHash and reduce the cost of un-packing and searching the inputs. This is especially prominent in the batching pattern where in 1 tx, we have dozens of script inputs that are doing this exact same thing. By reducing the cost of each script, we can marginally increase the total number of script inputs in the transaction (hence the throughput of Dapp).

Hey @micahkendall,

Since this proposal is currently very brief on all sections, I have converted it to a draft.

Hey @micahkendall,

Since this proposal is currently very brief on all sections, I have converted it to a draft.

What needs elaboration?

@micahkendall: What needs elaboration?

• The single-sentence Motivation
  • e.g. what problems have you run into without this? How often do these problems occur in general practice?
• The single-sentence Specification
  • what does the proposed code look like? what do examples of its usage look like?
• The single-sentence Rationale: maybe OK; depends on how much is covered in Motivation about why we are doing this & the alternatives.
• The cursory Path to Active: please see CIP-0035 to see what needs to be added for Plutus changes.
  • The requirements are strict for non-Core changes and even stricter for Core changes.
  • Please make them into checkboxes so implementors can mark these as resolved if & when it moves from Proposed to Active.
• Copyright requires open-source licensing for a reason you may not have considered: a disclaimer of liability. The community needs this as well as you. Please choose CC or Apache as required here for all CIPs: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0001/README.md#licensing

cc @Ryun1

p.s. @micahkendall a good start would be to put all the things from this PR's OP into the proposal itself. My last answer was just to address the editing question directly. But you have some good detail in your original posting that answers a lot of these "elaboration" questions & would at least provide a starting point for proper review in the document itself.

I think we should instead go for consistent integer indexes and fix #638 to get O(1) lookup in the inputs list.

The point of the ScriptPurpose is to be the information you need to identify the particular script invocation. Caching random additional information in it dilutes that purpose and it's not clear when you should include things or not.

I think we should instead go for consistent integer indexes and fix #638 to get O(1) lookup in the inputs list.

100% onboard with this. Would be an incredible improvement.

@michaelpj

If we're going to be getting O(1) lookup on inputs in time for Plutus V3 then I'm happy to withdraw this CIP. I think from a developer experience standpoint it's still sane to bring the information together, as it can hardly be considered random additional information when it is the exact information that every other script purpose variant contains. However to me that doesn't make it a meaningful improvement because I primarily care about performance.

I think it's pretty unlikely that any further significant changes to the script context are going to hit PlutusV3, sorry.